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:
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>
net: phy: dp83867: default to 2ns delay if unspecified in device-tree
Since Linux commit c360eb0c3ccb ("dt-bindings: net: ethernet-controller:
Add informative text about RGMII delays"), the interpretation of RGMII
delays has changed. Prior to the commit, the RGMII Variant among "rgmii",
"rgmii-id", "rgmii-rxid" and "rgmii-txid" clearly specified whether it is
the MAC or the PHY that "should" add the delay. However, post that commit,
the RGMII Variant only specifies whether or not there is a delay on the
PCB traces between the MAC and the PHY, leaving it open as to who adds the
delay.
Hence, instead of enforcing the existence of the device-tree properties
"ti,rx-internal-delay" and "ti,tx-internal-delay", default to a delay
of 2ns, while continuing to override this delay with the aforementioned
properties, if they exist in the device-tree.
This is in line with the Linux driver implementation updated by commit 6bf78849371d ("net: phy: dp83867: use 2ns delay if not specified in DTB").
Mathew McBride [Fri, 1 May 2026 01:36:08 +0000 (11:36 +1000)]
arm: dts: remove local copy of Ten64 board DTS
This board has been migrated to the upstream / kernel
device tree version (OF_UPSTREAM), so remove the
old 'local' copies that are no longer required.
However, the -u-boot.dtsi append needs to remain,
because the SoC fsl-ls1088a-u-boot.dtsi is required
for some devices (like PCIe controllers and DPAA2 ethernet)
to properly enumerate under U-Boot.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mathew McBride <matt@traverse.com.au> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Mathew McBride [Fri, 1 May 2026 01:36:07 +0000 (11:36 +1000)]
configs: ten64: switch to OF_UPSTREAM
Two recent additions to the mainline device tree allow us
to switch away from the local U-Boot copy:
* Board/embedded controller (traverse,ten64-controller)
is now in the mainline device tree.
* USB Hub (USB5744) connections were also added to
the mainline device tree but not in U-Boot.
The LS1088A and Ten64 device trees in U-Boot were actually
'synced' to mainline some time ago, so the content
(except for the changes mentioned above) is identical.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mathew McBride <matt@traverse.com.au> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ten64 board revs A through C have a Microchip USB5744
hub on the board, which must be configured over I2C
at boot time to become usable.
This function has not been part of the mainline
U-Boot for this board until now, as a mainline driver
and device-tree binding is now available for the USB5744.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mathew McBride <matt@traverse.com.au> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Mathew McBride [Fri, 1 May 2026 01:36:05 +0000 (11:36 +1000)]
configs: ten64: enable OF_BOARD_FIXUP
We have added board_fix_fdt to remove elements from U-Boot's
internal FDT related to the USB hub, so CONFIG_OF_BOARD_FIXUP
needs to be enabled to utilize it.
Signed-off-by: Mathew McBride <matt@traverse.com.au> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Mathew McBride [Fri, 1 May 2026 01:36:04 +0000 (11:36 +1000)]
board: ten64: remove USB hub references from internal FDT when needed
More recent revisions of the Ten64 board do not have a USB Hub
(USB5744). The references to the USB5744 need to be removed in U-Boot's
internal FDT to avoid the USB5744 setup being invoked on these boards.
Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mathew McBride <matt@traverse.com.au> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Mathew McBride [Fri, 1 May 2026 01:36:03 +0000 (11:36 +1000)]
board: ten64: add fdt fixup to hide usb hub topology
The USB Hub (microchip,usb5744) can enter a dis-/reconnect loop
if a driver tries to re-initialise the hub over I2C.
On the Ten64 board, this process only needs to be run once
per system reset cycle, which is carried out by U-Boot.
As there are distributions shipping with the affected
driver by default, the best solution is to remove
the USB hub topology information from the FDT passed
to the operating system, so the OS won't attempt
to re-initialise the USB hub under any circumstance.
Signed-off-by: Mathew McBride <matt@traverse.com.au> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Mathew McBride [Fri, 1 May 2026 01:36:02 +0000 (11:36 +1000)]
arm: gpio: include integer type definitions for gpio.h
Both consumers and sub-arch specific versions of gpio.h
may reference stdint or other non-C90 type definitions.
Ensure the common ones are available by including linux/types.h
before any other headers.
This issue came to light when the usb onboard hub driver
was enabled for ten64_tfa_defconfig:
In file included from ./arch/arm/include/asm/gpio.h:2,
from common/usb_onboard_hub.c:10:
./arch/arm/include/asm/arch/gpio.h:17:9: error: unknown type name 'ulong'
17 | ulong addr;
./arch/arm/include/asm/arch/gpio.h:18:9: error: unknown type name 'ulong'
18 | ulong size;
./arch/arm/include/asm/arch/gpio.h:19:9: error: unknown type name 'uint'
19 | uint ngpios;
(In this instance, the cited errors actually originate from
arch/arm/include/asm/arch-fsl-layerscape/gpio.h, which is included
by the arm top level asm/gpio.h)
Implemented as per suggestion from Quentin Schulz in Link:
When CONFIG_DM_SPI_FLASH is enabled, sf command will default find
device from DT which requires to use "jedec,spi-nor" compatible
string not obsoleted "spi-flash". So update NXP LS DTS to use
new compatible string
Signed-off-by: Ye Li <ye.li@nxp.com> Acked-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ye Li [Fri, 17 Apr 2026 14:16:36 +0000 (22:16 +0800)]
arm: dts: layerscape: Fix DT build warning in SPI nodes
There are lots of DT warning in layerscape DTS files like:
node name for SPI buses should be 'spi' and SPI bus unit address
format error.
Update the spi node name and flash node name to avoid build warning
Signed-off-by: Ye Li <ye.li@nxp.com> Acked-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ye Li [Fri, 17 Apr 2026 14:15:29 +0000 (22:15 +0800)]
arm: dts: fsl-ls1088a: Enable USB nodes
Enable USB nodes in -u-boot.dtsi. After sync dts with kernel, USB
nodes status are set to disabled. So "usb start" does not work on
ls1088ardb and ls1088aqds.
Fixes: 10ff7e6b043b ("arm: dts: fsl-ls1088a: sync usb controller nodes with Linux") Signed-off-by: Ye Li <ye.li@nxp.com> Tested-by: Wei Lu <w.lu@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ye Li [Fri, 17 Apr 2026 14:15:28 +0000 (22:15 +0800)]
arm: dts: fsl-ls1088a: Enable SD device
Due to update of fsl-ls1088a.dtsi in previous patch, the esdhc
node is disabled, so u-boot can't to probe any eSDHC controller.
Fixes: fd4f7b0158d0 ("arm: dts: fsl-ls1088a: move and sync existing bindings to be under /soc") Signed-off-by: Ye Li <ye.li@nxp.com> Tested-by: Wei Lu <w.lu@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ye Li [Fri, 17 Apr 2026 14:14:37 +0000 (22:14 +0800)]
arm: dts: fsl-ls1088a: Set dpmac nodes default to disabled
Disable ethernet controller dpmac nodes in fsl-ls1088a.dtsi. Board
dts is responsible to enable them. Otherwise will meet failure from
ldpaa_eth driver on LS1088AQDS board, because only few dpmac
controllers can be enabled on this board.
Signed-off-by: Ye Li <ye.li@nxp.com> Tested-by: Wei Lu <w.lu@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
LS1088AQDS u-boot contains multiple DTB files:
fsl-ls1088a-qds-21-x.dtb and fsl-ls1088a-qds-29-x.dtb.
It does not use default device tree fsl-ls1088a-qds.dtb
However, the nodes updated in fsl-ls1088a-qds-u-boot.dtsi are not
included for fsl-ls1088a-qds-21-x.dts and fsl-ls1088a-qds-29-x.dts,
so fail to get any output from serial.
Signed-off-by: Ye Li <ye.li@nxp.com> Tested-by: Wei Lu <w.lu@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ye Li [Thu, 16 Apr 2026 13:48:38 +0000 (21:48 +0800)]
arm: layerscape: Check zero size memory bank before lmb_add
In layerspace's lmb_arch_add_memory implementation, all memory bank
are added to lmb, even some is with zero size. This will cause lmb
treating it as overlap with available memory by lmb_addrs_overlap
and merge with available memory. Finally causing available memory
start address changed to 0.
For example, on LX2160, before zero memory bank added to lmb, there
are two available memory regions:
- region 0, start 0x80000000, size 0x7be00000
- region 1, start 0x2080000000, size 0x700000000
After zero size memory bank added, merge to one region:
- region 0, start 0, size 0x2780000000
This wrong new region causes efi_memory_init issue when allocating bounce
buffer because of conflict address (with uboot reserved) is allocated.
Signed-off-by: Ye Li <ye.li@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
mmc: msm_sdhci: Use max-frequency to get clock rate
msm_sdc_clk_init() uses clock-frequency to get the clock rate for SDC
clocks. However, the DT files seem to use max-frequency for the same.
Since msm_sdc_clk_init() doesn't find clock-frequency in the DT, it sets 201500000 as the clock rate and this results in timeout errors on IPQ
platforms.
Additionally, clock-frequency is not DT bindings compliant. Hence, get
clock rate using DT bindings compliant max-frequency.
Peng Fan [Sat, 18 Apr 2026 12:37:35 +0000 (20:37 +0800)]
power: regulator: Correct Kconfig for PFUZE100
Use CONFIG_$(PHASE_)DM_REGULATOR_PFUZE100 as the build condition for
pfuze100 regulator driver.
Add Kconfig option for SPL_DM_REGULATOR_PFUZE100.
To avoid break current platforms, set the Kconfig default value same
as PMIC_PFUZE100.
Peng Fan [Sat, 18 Apr 2026 12:37:34 +0000 (20:37 +0800)]
power: regulator: pfuze100: support non-independent mode
Some BUCKs could work in single/dual phase mode, not in independent
mode. In single/dual phase mode, registers of both regulators,
must be identically set. So configure mode and value for both BUCKs.
CONF registers are not touched, leave them as default OTP settings.
PFUZE100/200 SW3A/B, could work in single/dual phase mode, so introduce
a new macro by adding a pointer to the SW3B descriptor.
Peng Fan [Sat, 18 Apr 2026 12:37:33 +0000 (20:37 +0800)]
power: regulator: pfuze100: support high output voltage mode
Some PFUZE regulators can operate in either low or high output voltage mode,
with different minimum voltages and voltage step sizes selected by a hardware
control bit. However, the current PFUZE100 regulator driver assumes low output
voltage mode only, resulting in incorrect voltage calculation and programming
when high voltage mode is enabled.
Extend the regulator descriptor to describe high output voltage mode by adding
a mask to detect the mode and a dedicated voltage description (min_uV and
step size). Update voltage get/set handling to dynamically select the correct
voltage parameters based on the high voltage mode bit.
Peng Fan [Sat, 18 Apr 2026 12:37:32 +0000 (20:37 +0800)]
power: regulator: pfuze100: Fix min_uV usage
regulator-min-microvolt in device tree is not always match the minimal
voltage in the pmic datasheet, direclty using the min value from device
tree as base may cause wrong voltage settings being written.
Directly use the min_uV from datasheet to avoid wrong settings.
Depending on the phase selection (single or multi), the FPWM bits
configured forces the regulator to operate in PWM mode. In case of
multi-phase selection, the FPWM_MP bits enforce the regulator to also
operate in multi-phase. This fixes correct multi-phase operation.
While at this, correct incorrect macro alignment as well.
Tom Rini [Tue, 5 May 2026 16:37:16 +0000 (10:37 -0600)]
Merge patch series "binman: Fix preload signing with encrypted FIT"
Yan WANG <yan.wang@softathome.com> says:
This series improves the reliability and efficiency of binman preload
header generation and test it against an encrypted FIT image signed with
a preload header.
When a preload header references other entries (e.g. an encrypted FIT)
through the collection etype, the referenced entries may be rebuilt
multiple times during binman processing. This becomes problematic when
the referenced entry produces non-deterministic output, such as FIT
encryption using random IVs or timestamps, since rebuilding the entry
changes the data.
This series ensures that referenced entries are built only once and that
preload signing is performed after all data is collected. It also avoids
unnecessary repacking or repeated signing operations by the preload.
The changes include:
* generate preload header placeholders in ObtainContents() and sign
data only once in ProcessContentsUpdate()
* mark referenced entries as build_done in the collection etype to
avoid rebuilding data
* add a functional test for signing an encrypted FIT with a preload
header
Paul HENRYS [Fri, 17 Apr 2026 08:30:50 +0000 (10:30 +0200)]
tools: binman: Test signing an encrypted FIT with a preload header
Add a test to verify the preload header correctly signs an encrypted
FIT. This test exercises the case where encryption uses random IVs that
would change between mkimage calls.
Signed-off-by: Paul HENRYS <paul.henrys_ext@softathome.com> Reviewed-by: Simon Glass <sjg@chromium.org>
yan wang [Fri, 17 Apr 2026 08:30:49 +0000 (10:30 +0200)]
binman: collection: Set build_done on referenced entries
The collection etype uses phandles in the 'content' property to
reference other entries. Mark each referenced entry with build_done
to avoid rebuilding the same entry data multiple times.
This is important for cases where rebuilding may change the data
content, e.g. due to timestamps or random IVs in encryption.
Refactor GetContentsByPhandle() to return both the entry object and
its data.
Signed-off-by: yan wang <yan.wang@softathome.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Paul HENRYS [Fri, 17 Apr 2026 08:30:48 +0000 (10:30 +0200)]
binman: Generate preload header and sign data only once
To optimize preload generation, generate the header and signatures only
after all data has been collected in ProcessContentsUpdate(). This
avoids signing the data multiple times.
Since header_size is known upfront (from __init__), create a placeholder
in `ObtainContents()` to avoid an extra packing pass when
ProcessContentsUpdate() detects a size change.
This reduces unnecessary repacking and signing operations.
Signed-off-by: Paul HENRYS <paul.henrys_ext@softathome.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Tue, 5 May 2026 16:36:08 +0000 (10:36 -0600)]
Merge patch series "configs: toradex: Enable EFI"
Francesco Dolcini <francesco.dolcini@toradex.com> says:
Enable standard EFI support for all the arm64 Toradex boards, as
required for booting standard aarch64 Linux distribution, following the
ARM recommendations for SystemReady compliance.
The RTC used on these boards is not currently supported by U-Boot,
therefore it is not enabled at the moment.
Enable EFI related options, as suggested for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
configs: verdin-imx8mp: Enable EFI related options
Enable EFI related options, as suggested for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
configs: verdin-imx8mm: Enable EFI related options
Enable EFI related options, as suggested for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
Enable EFI related options, as suggested for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
Enable EFI related options, as suggested for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
projects / thirdparty / u-boot.git / log
