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
Frank Wunderlich <frank-w@public-files.de> says: Add command for getting ramsize in scripts Link: https://lore.kernel.org/r/20260204184045.111808-1-linux@fw-web.de
Add a test for memsize command in same way as meminfo. Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Add a command for getting detected ram size with possibility to assign it to an environment variable. example usage: BPI-R4> memsize 4096 MiB BPI-R4> memsize memsz BPI-R4> printenv memsz memsz=4096 BPI-R4> board with 8GB ram: BPI-R4> memsize 8192 MiB BPI-R4> memsize memsz BPI-R4> printenv memsz memsz=8192 BPI-R4> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
The net_loop() currently conflates return value with file size at the end of successful transfer, in NETLOOP_SUCCESS state. The return type of net_loop() is int, which makes this practice workable for file sizes below 2 GiB, but anything above that will lead to overflow and bogus negative return value from net_loop(). The return file size is only used by a few sites in the code base, which can be easily fixed. Change the net_loop() return value to always be only a return code, in case of error the returned value is the error code, in case of successful transfer the value is 0 or 1 instead of 0 or net_boot_file_size . This surely always fits into a signed integer. By keeping the return code 0 or 1 in case of successful transfer, no conditionals which depended on the old behavior are broken, but all the sites had to be inspected and updated accordingly. Fix the few sites which depend on the file size by making them directly use the net_boot_file_size variable value. This variable is accessible to all of those sites already, because they all include net-common.h . Signed-off-by: Yuya Hamamachi <yuya.hamamachi.sx@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Unmap the sysmem that got mapped by this command. Use symbolic return value for the command while updating the return value handling. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The current implementation casts an address to a pointer. Make it more sandbox-friendly by using map_sysmem(). Use symbolic return value for the command while updating the return value handling. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The current implementation casts an address to a pointer. Make it more sandbox-friendly by using map_sysmem(). Convert 'addr' variable to unsigned long, as that is the return type of hextoul() and address parameter type of map_sysmem(). Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
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>
Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> says: It was noted that a GPT partition with the maximum available partition number (ex: /dev/mmcblk128) can't be read/write from U-Boot using read/write commands. Futher investigation shows that the problem is deeper. This set of patches fixes uncovered issues. Link: https://lore.kernel.org/r/20260119223305.3022690-1-mikhail.kshevetskiy@iopsys.eu