Fix a few UEFI function names, as well as a typo.

Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Add a test calling the LoadImage() UEFI function with both its SourceBuffer
and DevicePath input arguments equal to NULL.

This test can be run on the sandbox with the following command:

  ./u-boot -T -c "setenv efi_selftest load image from file; \
                  bootefi selftest"

Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>

When the LoadImage() UEFI function is called with both its SourceBuffer and
DevicePath input arguments equal to NULL, it must return EFI_NOT_FOUND [1].
However, it does return EFI_INVALID_PARAMETER instead; fix it.

Link: https://uefi.org/specs/UEFI/2.11/07_Services_Boot_Services.html#efi-boot-services-loadimage [1]
Reported-by: Sathisha Shivaramappa <sathisha.shivaramappa@arm.com>
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>

The size of the memory allocated for the EFI Conformance Profiles Table is
computed with `num_entries' always equal to zero, which is incorrect when
CONFIG_EFI_EBBR_2_1_CONFORMANCE is enabled.

This can be verified by allocating the ECPT memory with malloc() instead of
efi_allocate_pool(), building u-boot with sandbox_defconfig and
CONFIG_VALGRIND=y, and by finally running the following command:

  valgrind --suppressions=scripts/u-boot.supp \
    ./u-boot -T -c 'efidebug tables'

Fix this by using an array of the supported profiles GUIDs instead, which
should also be easier to extend in the future as U-Boot should publish the
GUIDs for all supported EBBR revisions.

Fixes: 6b92c1735205 ("efi: Create ECPT table")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Jose Marinho <jose.marinho@arm.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

The read_blocks() function from the Block IO protocol is a UEFI function;
make sure to call it from within U-Boot using the EFI_CALL() macro.

To demonstrate the issue on an AArch64 machine, define the DEBUG macro in
include/efi_loader.h and build u-boot with sandbox_defconfig, then download
and uncompress the ACS-DT image [1], and finally execute the following
command:

  $ ./u-boot -T -c " \
      host bind 0 systemready-dt_acs_live_image.wic; \
      setenv loadaddr 0x10000; \
      load host 0 \${loadaddr} EFI/BOOT/Shell.efi; \
      bootefi \${loadaddr} \${fdtcontroladdr}"

The following assertion should fail:

  lib/efi_loader/efi_net.c:858: efi_network_timer_notify: Assertion `__efi_entry_check()' failed.

This happens due to the following EFIAPI functions call chain:

  efi_start_image()
    efi_disk_read_blocks()
      (due to the missing EFI_CALL, entry_count == 2)
      efi_network_timer_notify()

Link: https://github.com/ARM-software/arm-systemready/releases/download/v25.12_DT_3.1.1/systemready-dt_acs_live_image.wic.xz [1]
Fixes: ce3dbc5d080d ("efi_loader: add UEFI GPT measurement")
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Masahisa Kojima <kojima.masahisa@socionext.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Masahisa Kojima <kojima.masahisa@socionext.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

Coverity scan reported:

CID 449815:         Memory - illegal accesses  (OVERRUN)
Overrunning array of 64 bytes at byte offset 64 by dereferencing pointer
"sctx->buffer + partial". [Note: The source code implementation of the
function has been overridden by a builtin model.]

In line: 252
   memset(sctx->buffer + partial, 0, SM3_BLOCK_SIZE - partial);

The respective line should be:

memset(sctx->buffer + partial, 0, SM3_BLOCK_SIZE - partial - 1);

as partial gets incremented by one before.

Signed-off-by: Heiko Schocher <hs@nabladev.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Pull request net-20260209.

net:
- airoha: mdio support for the switch
- phy: mscc: allow RGMII with internal delay for the VSC8541
- dwc_eth_qos: Update tail pointer handling

net-legacy:
- Stop conflating return value with file size in net_loop()

net-lwip:
- wget: rework the '#' printing
- tftp: add support of tsize option to client

Pull request efi-2026-04-rc2

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

Documentation:

* Remove pip from requirements.txt
* develop/process: Clarify name usage in the Signed-off-by line

UEFI:

* Improve EFI variable load message
* Fix use after free in efi_exit() with tcg2
* Fix efi_debug_image_info_normal allocation
* Add missing EFI_CALL in efi_net

The TFTP server can report the size of the entire file that is about to
be received in the Transfer Size Option, this is described in RFC 2349.
This functionality is optional and the server may not report tsize in
case it is not supported.

Always send tsize request to the server to query the transfer size,
and in case the server does respond, cache that information locally
in tftp_state.tsize, otherwise cache size 0. Introduce new function
tftp_client_get_tsize() which returns the cached tftp_state.tsize so
clients can determine the transfer size and use it.

Update net/lwip/tftp.c to make use of tftp_client_get_tsize() and
avoid excessive printing of '#' during TFTP transfers in case the
transfer size is reported by the server.

Submitted upstream: https://savannah.nongnu.org/patch/index.php?item_id=10557

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-by: Jerome Forissier <jerome.forissier@arm.com>

The only call site of gzwrite() is cmd/unzip.c do_gzwrite(), where
the 'len' parameter passed to gzwrite(..., len, ...) function is of
type unsigned long. This usage is correct, the 'len' parameter is
an unsigned integer, and the gzwrite() function currently supports
input data 'len' of up to 4 GiB - 1 .

The function signature of gzwrite() function in both include/gzip.h
and lib/gunzip.c does however list 'len' as signed integer, which
is not correct, and ultimatelly limits the implementation to only
2 GiB input data 'len' .

Fix this, update gzwrite() function parameter 'len' data type to
size_t consistently in include/gzip.h and lib/gunzip.c .

Furthermore, update gzwrite() function 'szwritebuf' parameter in
lib/gunzip.c from 'unsigned long' to 'size_t' to be synchronized
with include/gzip.h . Rewrite the other parameters to size_t and
off_t and propagate the change too.

Since the gzwrite() function currently surely only supports input
data size of 4 GiB - 1, add input data size check. The limitation
comes from the current use of zlib z_stream .avail_in parameter,
to which the gzwrite() function sets the entire input data size,
and which is of unsigned int type, which cannot accept any number
beyond 4 GiB - 1. This limitation will be removed in future commit.

Reported-by: Yuya Hamamachi <yuya.hamamachi.sx@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>