u-boot.git/lib, branch next

Merge tag 'v2026.10-rc3' into next

2026-08-25T01:31:25Z

lmb: Return -EFAULT when freeing unallocated memory regions

2026-08-24T19:58:00Z

Make lmb_free() return -EFAULT when the requested memory region is not allocated, instead of the generic -1 error value. Document the updated error code in the public API comment and change the LMB unit test to check for the new -EFAULT errno value. Signed-off-by: Jonas Karlman Reviewed-by: Randolph Sapp

lmb: Return -EFAULT when requested region is not part of memory map

2026-08-24T19:58:00Z

lmb_alloc_addr() is documented to return -EINVAL when the requested memory region is not part of the LMB memory map. However, -EINVAL is also used to e.g. indicate that a NULL pointer is passed as the addr parameter or when the requested memory region partially overlaps an existing region. Change lmb_alloc_addr() to return -EFAULT when the requested memory region is not part of the LMB memory map to make the type of error known to callers. Also extend unit tests to validate that the return code has stay the same when the requested memory region partially overlaps. No caller of lmb_alloc_addr() is checking what type of error code is returned, so this change has no intended behavior change. Signed-off-by: Jonas Karlman Reviewed-by: Randolph Sapp

Merge patch series "gunzip: Fix spurious Z_BUF_ERROR in chunked gzwrite decompression"

2026-08-20T18:15:24Z

Aristo Chen says: The dm_test_cmd_zip_gzwrite sandbox test occasionally fails in CI with: 12582912/16777216 Error: inflate() returned -5 The chunked decompression loop added in commit 58e523fedf48 ("gunzip: Implement chunked decompression") treats Z_BUF_ERROR from inflate() as fatal. When an input chunk is exhausted at exactly the same time as the write buffer fills up, the next inflate() call is made with avail_in == 0, cannot make progress, and returns Z_BUF_ERROR. Per the zlib documentation this only means "no progress was possible" and the call should be repeated with more input, which is what the reference implementation in zlib examples/zpipe.c does. The failure needs the consumed/produced byte counts to line up with both the chunk size and the write buffer size at once, with no buffered output on the inflate side, which is why only certain random payloads trigger it. Note that the failure offset above is a multiple of the 1 MiB write buffer while gzwrite_chunk was SZ_1M + 1. Patch 1 makes gzwrite() refill the input chunk in this situation. Patch 2 adds a deterministic regression test which builds a gzip file from two stored deflate blocks by hand and aligns the chunk boundary with the write buffer boundary exactly, failing reliably without patch 1. Verified on sandbox and sandbox64: - dm_test_cmd_gzwrite_chunk_boundary fails with -5 in 20 out of 20 runs before the fix, passes 100 out of 100 runs after - dm_test_cmd_zip_gzwrite fails 17 out of 2000 runs (about 1%) before the fix, every time with the same signature as the CI flake, and passes 2000 out of 2000 runs after - dm_test_cmd_zip_unzip keeps passing Link: https://lore.kernel.org/r/20260808004437.4367-1-aristo.chen@canonical.com

gunzip: Fix spurious Z_BUF_ERROR in chunked gzwrite decompression

2026-08-20T15:59:25Z

The chunked decompression loop in gzwrite() treats any inflate() return value other than Z_OK and Z_STREAM_END as a fatal error. When the current input chunk happens to be exhausted at exactly the same time as the write buffer fills up, the inner loop calls inflate() again with avail_in == 0. No forward progress is possible in that state, so inflate() returns Z_BUF_ERROR and gzwrite() bails out: Error: inflate() returned -5 Per the zlib documentation, Z_BUF_ERROR is not fatal and only means that no progress was possible; the call should be repeated once more input is available. The reference implementation in zlib examples/zpipe.c continues in this exact situation. The failure is data dependent: it needs a stream position where the consumed input and produced output line up with both the chunk and the write buffer boundary at once, and the inflate side must have no buffered output. That is most likely with incompressible input, where deflate emits stored blocks and inflate holds no lookahead bits. This is how dm_test_cmd_zip_gzwrite occasionally fails in sandbox64 CI on random data with gzwrite_chunk = SZ_1M + 1, stopping at a multiple of the 1 MiB write buffer: 12582912/16777216 Error: inflate() returned -5 Detect this case and let the outer loop refill the input chunk instead of failing. On sandbox64, the random data dm_test_cmd_zip_gzwrite test failed 17 out of 2000 runs (about 1 percent) without this fix, every time with the same signature as the CI flake, and passed 2000 out of 2000 runs with it. Fixes: 58e523fedf48 ("gunzip: Implement chunked decompression") Signed-off-by: Aristo Chen Reviewed-by: Simon Glass

Merge tag 'net-20260813' of https://git.u-boot-project.org/u-boot/custodians/u-boot-net

2026-08-13T14:58:29Z

Pull request net-20260813. net: - phy: dp83867: enable extended read / write for driver - phy: fix duplicate eth_phy binding - Drop unnecessary device_set_name - dwc_eth_xgmac: Return -ENODEV when phy_connect() fails - nfs: clean up bounds checks in nfs_readlink_reply() - rtl8169: add support for RTL8126A and RTL8127A - srand_mac(): fix -ENODEV crash with CONFIG_DM_RNG net-legacy: - Fix out-of-bounds write in IP fragment reassembly - test: net: add regression test for IP reassembly overflow net-lwip: - Add tftpsrv command - Handle chained pbufs in transmit path - sntp: fix netif leak when ntpserverip is unset - wget: free mbedtls x509 cert context to avoid memory leak - Fix DHCP fine timer interval

Merge patch series "lib: resync lib/div64.c and with Linux v7.1"

2026-08-11T18:49:09Z

Alexey Charkov says: U-Boot's was last really synced with Linux in 2017 by commit 0342e335ba88 ("lib: div64: sync with Linux"). Since then it has only been patched locally twice, and both times in ways that increased the divergence rather than tracking upstream. The one that prompted this series is DIV64_U64_ROUND_UP(). Commit 3adc17f60bf8 ("lib: div64: Add support for round up of div64_u64") added it inside the #if BITS_PER_LONG == 64 branch, whereas upstream defines it unconditionally after that block, so any 32-bit user fails to build. While auditing the header, two bugs turned up in lib/div64.c, so this series starts with those. Both are 32-bit only: - div64_u64() and div64_u64_rem() shifted by 1 + fls(high) instead of fls(high), losing a bit of the divisor. Linux fixed this in 2019, while U-Boot never picked it up. - div64_s64() used abs() on s64 operands. U-Boot's abs() is not 64-bit safe: its own comment says to use abs64() instead. Both operands were silently truncated to 32 bits. Transitive headers that affect what offers were checked too. and have no U-Boot equivalent and are not needed; do_div() comes from U-Boot's in place of . Deliberately left out of this resync: - CONFIG_ARCH_SUPPORTS_INT128 is tested by but isn't defined anywhere in U-Boot, so the __int128 fast paths for mul_u64_u32_shr() and mul_u64_u64_shr() are dead code on arm64, riscv64 and x86_64 where they could have been useful. Wiring it up in the arch Kconfigs looks like an easy win (but could result in subtle behavior changes or code size drift, so needs to be approached separately). - abs() in diverges from Linux and is not 64-bit safe. Patch 2 and patch 5 work around it with abs64() at the two call sites that need it. Replacing it with Linux's __abs_choose_expr() version would be the root fix, but changes abs()'s return type from long to typeof(x) for every caller in the tree. - abs_diff() lives in here rather than upstream's ; it could move to alongside abs(). - mul_u64_add_u64_div_u64() and the mul_u64_u64_div_u64() macros are not ported, as they need a u128 type and ~110 lines of lib/math/div64.c that nothing in U-Boot calls yet. Build tested with both gcc and clang for evb-rk3288-rk808 (32-bit LE), generic-rk3576 (64-bit LE), malta (32-bit big-endian, which is what actually compiles the __BIG_ENDIAN union paths), plus sandbox and tools-only. No size change on any phase. Link: https://git.u-boot-project.org/u-boot/contributors/alchark/u-boot/-/pipelines/812 Link: https://lore.kernel.org/r/20260730-math64-resync-v1-0-8792d9119d49@flipper.net

lib: div64: sync with Linux v7.1

2026-08-11T18:48:50Z

Bring the structure of this file in line with Linux v7.1 lib/math/div64.c, so that future resyncs are a near-verbatim diff. No functional change: the compiled lib/div64.o is byte-identical before and after, verified by comparing objdump -d output for both evb-rk3288-rk808_defconfig (32-bit, where these out-of-line helpers are actually built) and generic-rk3576_defconfig (64-bit). - Add the SPDX license identifier, as upstream did in commit b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to files with no license"). - Demote the kernel-doc blocks on div64_u64_rem() and div64_u64() to plain comments and drop the one on div64_s64() entirely, following upstream commit d28a1de5d112 ("math64: favor kernel-doc from header files"). The kernel-doc for these lands in in a later patch of this series; keeping it in both places would only let the two copies drift apart. - Guard iter_div_u64_rem() with #ifndef iter_div_u64_rem, matching upstream, so an arch can override it the same way it can override the other helpers here. Two U-Boot-local deviations are kept deliberately and are now marked as such so that the next resync does not silently drop them: - __div64_32() carries a no_instrument_function attribute, needed because CONFIG_TRACE builds with -finstrument-functions and this function is reachable from tracing code via do_div(). - The includes stay as they are. provides U-Boot's no-op EXPORT_SYMBOL() in place of upstream's , and provides abs()/abs64() in place of upstream's , which U-Boot does not have. The u32/u64 spelling is also left alone rather than converted to Linux's uint32_t/uint64_t: U-Boot's already made the opposite choice, and matching Linux here would make the two files inconsistent for no benefit. Signed-off-by: Alexey Charkov Reviewed-by: Simon Glass

lib: div64: inline __iter_div_u64_rem() into its only user

2026-08-11T18:48:50Z

__iter_div_u64_rem() is only split out in Linux for its vDSO header, which has no use in U-Boot. Inline the body of the helper directly into its only user, which is the iter_div_u64_rem() wrapper in this same file, and drop the static inline, so that a subsequent resync of include/linux/math64.h against Linux does not have to carry an exception for it. include/vdso/math64.h is deliberately not created: its only other resident, mul_u64_u32_add_u64_shr(), has no U-Boot user. No functional change: the generated code is identical, verified by comparing objdump -d of lib/div64.o before and after for evb-rk3288-rk808_defconfig. The compiler was already inlining the sole call. iter_div_u64_rem() itself has no in-tree callers either, but it is upstream API and is left in place. Signed-off-by: Alexey Charkov Reviewed-by: Simon Glass

lib: div64: use abs64() for the 64-bit operands of div64_s64()

2026-08-11T18:48:50Z

Both operands of div64_s64() are s64, but U-Boot's abs() is not 64-bit safe. Unlike its Linux counterpart, which dispatches on the argument type down to long long, U-Boot's abs() evaluates its argument as int whenever sizeof(x) != sizeof(long) and yields a long. The header even says so: "abs() should not be used for 64-bit types (s64, u64, long long) - use abs64() for those." So on BITS_PER_LONG == 32 both operands are silently truncated to 32 bits before the division. Simulating the macro with long narrowed to 32 bits shows what reaches div64_u64(): x= -4294967296 abs()= 0 abs64()= 4294967296 x= -5000000000 abs()= 705032704 abs64()= 5000000000 x=-9223372036854775807 abs()= 1 abs64()= 9223372036854775807 A zero from the first case makes the subsequent division a divide by zero rather than merely imprecise. div64_s64() has no in-tree callers today, so this is a latent bug and not a regression. Note that the abs() in div_s64_rem() is correct as-is and deliberately left alone. Fixes: 0342e335ba88 ("lib: div64: sync with Linux") Signed-off-by: Alexey Charkov Reviewed-by: Simon Glass