Peng Fan (OSS) <peng.fan@oss.nxp.com> says:

This patch set primarily removes unused DECLARE_GLOBAL_DATA_PTR
instances.

Many files declare DECLARE_GLOBAL_DATA_PTR and include
asm/global_data.h even though gd is never used. In these cases,
asm/global_data.h is effectively treated as a proxy header, which is
not a good practice.

Following the Include What You Use principle, files should include
only the headers they actually depend on, rather than relying on
global_data.h indirectly. This approach is also adopted in Linux kernel
[1].

The first few patches are prepartion to avoid building break after
remove the including of global_data.h.

A script is for filtering the files:
list=`find . -name "*.[ch]"`
for source in ${list}
do
        result=`sed -n '/DECLARE_GLOBAL_DATA_PTR/p' ${source}`
        if [ "${result}" == "DECLARE_GLOBAL_DATA_PTR;" ]; then
                echo "Found in ${source}"

                result=`sed -n '/\<gd\>/p' ${source}`
                result2=`sed -n '/\<gd_/p' ${source}`
                result3=`sed -n '/\<gd->/p' ${source}`
                if [ "${result}" == "" ] && [ "${result2}" == "" ] && [ "${result3}" == "" ];then
                        echo "Cleanup ${source}"
                        sed -i '/DECLARE_GLOBAL_DATA_PTR/{N;/\n[[:space:]]*$/d;s/.*\n//;}' ${source}
                        sed -i '/DECLARE_GLOBAL_DATA_PTR/d' ${source}
                        sed -i '/global_data.h/d' ${source}
                        git add ${source}
                fi
        fi
done

[1] https://lpc.events/event/17/contributions/1620/attachments/1228/2520/Linux%20Kernel%20Header%20Optimization.pdf

CI: https://github.com/u-boot/u-boot/pull/865

Link: https://lore.kernel.org/r/20260209-cleanup-v2-0-73a3a84ddbdb@nxp.com

Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and
drop the unnecessary inclusion of asm/global_data.h.

Headers should be included directly by the files that need them,
rather than indirectly via global_data.h.

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal <anshuld@ti.com> #TI boards
Acked-by: Yao Zi <me@ziyao.cc> #TH1520
Signed-off-by: Peng Fan <peng.fan@nxp.com>

The TFTP transfer size is unsigned integer, update the data type
and print formating string accordingly to prevent an overflow in
case the file size is longer than 2 GiB.

TFTP transfer of a 3 GiB file, before (wrong) and after (right):
Loading: #################################################  16 EiB
Loading: ##################################################  3 GiB

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

Given how the support for CONFIG_CMD_TFTPPUT is woven through the
support for the tftp protocol we currently end up including "put"
support in xPL phases, if enabled. This in turn can lead to size
overflow on those platforms as xPL tends to be constrained. To resolve
this, use "CMD_TFTPPUT" in the code to check for both CONFIG_CMD_TFTPPUT
being true and not being in an xPL build phase.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jerome Forissier <jerome@forissier.org>

tftp_init_load_addr() always returns 0 since commit af45c84871e4 ("tftp:
rework the logic to validate the load address"), so we don't need to
check if it failed and can remove the error handling.
Also change tftp_init_load_addr() to static void since the return value
is now unused.

Signed-off-by: Leonard Anderweit <l.anderweit@phytec.de>
Reviewed-by: Yannic Moog <y.moog@phytec.de>

A few lines of code being guarded by the CONFIG_TFTP_PORT option seems
an unnecessary restriction on the TFTP support provided by a vanilla
U-Boot image. In cases where the TFTP server cannot run as superuser -
and hence cannot run on the well-known port 69 - this quirk incurs a
full reconfiguration and rebuild of the bootloader only in order to
select the appropriate destination port.

Remove the CONFIG_TFTP_PORT option entirely and make the tftpdstp and
tftpsrcp variables always have an effect. Their being unset will mean
that U-Boot behaves the same as if CONFIG_TFTP_PORT was unset. Update
the documentation accordingly. And fix up the single board which was
originally enabling this option.

Signed-off-by: Alvin Šipraga <alvin@pqrs.dk>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Contrary to doc/develop/driver-model/ethernet.rst contract, eth_ops
.free_pkt can be called after .stop, there are several error paths in TFTP,
for instance:

eth_halt() <= tftp_handler() <= net_process_received_packet() <= eth_rx()
...
am65_cpsw_free_pkt() <= eth_rx()

Which results in (deliberately "tftpboot"ing non-existing file):

TFTP error: 'File not found' (1)
Not retrying...
am65_cpsw_nuss_port ethernet@8000000port@1: RX dma free_pkt failed -22

Avoid the DMA error message (and follow the documentation) by deferring
eth_halt() until net_loop() calls net_start_again() and only do
eth_halt_state_only() instead.

Fixes: aafda38fb266 ("Add error codes/handling for TFTP-server")
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>

timeout_count is never reset once a tftpput transfer has started. If for
whatever reason timeouts occur frequently, but the server keeps replying
nonetheless, the transfer may be needlessly aborted.

Reset timer_count on reception of an ACK to avoid this situation.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

We have a some boards that rarely starts networking abnormally, so there are
many timeouts during file transfer. In the same time there is a normal transfer
between timeouts. In this case we can continue transfer (instead of connection
aborting) by just clearing timeout counter on every successful block.

This patch does not affect the case when several timeouts happen one after
another. The transfer will be aborted. Thus the transfer will be
continued in the case of unstable link, but will be aborted in the case
of inaccessible server.

Feature downside: it may greatly slowdown (instead of abort) file transfer
in the case of unstable link.

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

Implement support for LED activity. If the feature is enabled,
make the defined ACTIVITY LED to signal traffic.

Also turn the ACTIVITY LED OFF if a CTRL-C is detected in the main
net loop function.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>