- Oct 17, 2024
-
-
https://source.denx.de/u-boot/custodians/u-boot-dfuTom Rini authored
u-boot-dfu-20241017 CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/22742 Usb Gadget: - Fix cdns3 endpoint configuration by setting maxpacket - Fix dwc3 cache handling when using DMA Fastboot: - Make AVB_VERIFY depends on FASTBOOT
-
-
Add new section for USB TypeC Port Manager (TCPM) support, which is needed to figure out cable orientation of USB-C plus and to do USB PD communication. Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by:
Marek Vasut <marex@denx.de>
-
Now that all code has been prepared update the default configuration to make use of it. Reviewed-by:
Kever Yang <kever.yang@rock-chips.com> Tested-by:
Soeren Moch <smoch@web.de> Tested-by:
Anand Moon <linux.amoon@gmail.com> Reviewed-by:
Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
-
Add USB-C controller (fusb302), which will be used by U-Boot to initialize USB-PD. This is needed, because USB-PD communication must happen within 5 seconds after the USB-C connector got plugged. On my Rock 5B it often takes 5 seconds to jump to the Linux binary, so it must happen before Linux is initialized. This adds the DT node to the U-Boot specific file, since the Linux kernel DT currently does not describe it to avoid a system reset. The plan is to add it to the Linux DT with status = 'fail' and then let U-Boot mark it as status = 'okay' if it properly dealt with early USB-PD initialization. Until the Kernel DT has the node, let's add it in U-Boot to get things going. Reviewed-by:
-
Since older U-Boot releases do not negotiate USB PD, the kernel DT may not enable the USB-C controller by default to avoid a regression. The plan is to upstream it with 'status = "fail";' instead. U-Boot should then mark it as 'status = "okay";' if it negotiated USB PD. Currently existing upstream kernel DTs do not yet have the USB-C controller at all, so we ignore any failures. Reviewed-by:
-
Now that the TCPM framework exists we can introduce fusb302 driver using it. This chip is a very common USB-C controller chip with PD support, which can be found in the Radxa Rock 5B among many other boards. Apart from Power Delivery, it also handles detection of the cable orientation. That can be used to control a mux for connecting the right USB3 lane pair to the USB3 controller. The driver is originally from the Linux kernel, but has been adapted to the requirements of U-Boot and its TCPM framework. Co-developed-by:
Wang Jie <dave.wang@rock-chips.com> Signed-off-by:
-
This adds TCPM framework in preparation for fusb302 support, which can handle USB power delivery messages. This is needed to solve issues with devices, that are running from a USB-C port supporting USB-PD, but not having a battery. Such a device currently boots to the kernel without interacting with the power-supply at all. If there are no USB-PD message replies within 5 seconds, the power-supply assumes the peripheral is not capable of USB-PD. It usually takes more than 5 seconds for the system to reach the kernel and probe the I2C based fusb302 chip driver. Thus the system always runs into this state. The power-supply's solution to fix this error state is a hard reset, which involves removing the power from VBUS. Boards without a battery (or huge capacitors) will reset at this point resulting in a boot loop. This imports the TCPM framework from the kernel. The porting has originally been done by Rockchip using hardware timers and the Linux kernel's TCPM code from some years ago. I had a look at upgrading to the latest TCPM kernel code, but that beast became a lot more complex due to adding more USB-C features. I believe these features are not needed in U-Boot and with multiple kthreads and hrtimers being involved it is non-trivial to port them. Instead I worked on stripping down features from the Rockchip port to an even more basic level. Also the TCPM code has been reworked to avoid complete use of any timers (Rockchip used SoC specific hardware timers + IRQ to implement delayed work mechanism). Instead the delayed state changes are handled directly from the poll loop. Note, that (in contrast to the original Rockchip port) the state machine has the same hard reset quirk, that the kernel has - i.e. it avoids disabling the CC pin resistors for devices that are not self-powered. Without that quirk, the Radxa Rock 5B will not just end up doing a machine reset when a hard reset is triggered, but will not even recover, because the CPU will loose power and the FUSB302 will keep this state because of leak voltage arriving through the RX serial pin (assuming a serial adapter is connected). This also includes a 'tcpm' command, which can be used to get information about the current state and the negotiated voltage and current. Co-developed-by:
-
- Oct 16, 2024
-
-
Tom Rini authored
Rasmus Villemoes <ravi@prevas.dk> says: Some small improvements to the serial rx buffer feature. CI seems happy: https://github.com/u-boot/u-boot/pull/674 Link: https://lore.kernel.org/r/20241003141029.920035-1-ravi@prevas.dk
-
The initialization of upriv->buf doesn't check for a NULL return. But there's actually no point in doing a separate, unconditional malloc() in post_probe; we can just make serial_dev_priv contain the rx buffer itself, and let the (larger) allocation be handled by the driver core when it allocates the ->per_device_auto. The total run-time memory used is mostly the same, we reduce the code size a little, and as a bonus, struct serial_dev_priv does not contain the unused members when !SERIAL_RX_BUFFER. Signed-off-by:
Rasmus Villemoes <ravi@prevas.dk> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
The help text says it must be a power of 2, and the implementation does rely on that. Enforce it. A violation gives a wall of text, but the last few lines should be reasonably obvious: drivers/serial/serial-uclass.c:334:9: note: in expansion of macro ‘BUILD_BUG_ON_NOT_POWER_OF_2’ 334 | BUILD_BUG_ON_NOT_POWER_OF_2(CONFIG_SERIAL_RX_BUFFER_SIZE); Signed-off-by:
-
Before the previous patch, pasting a string of length x > CONFIG_SERIAL_RX_BUFFER_SIZE results in getting the last (x%CONFIG_SERIAL_RX_BUFFER_SIZE) characters from that string. With the previous patch, one instead gets the last CONFIG_SERIAL_RX_BUFFER_SIZE characters repeatedly until the ->rd_ptr catches up. Both behaviours are counter-intuitive, and happen because the code that checks for a character available from the hardware does not account for whether there is actually room in the software buffer to receive it. Fix that by adding such accounting. This also brings the software buffering more in line with how most hardware FIFOs behave (first received characters are kept, overflowing characters are dropped). Signed-off-by:
-
The current implementation of the circular rx buffer falls into a common trap with circular buffers: It keeps the head/tail indices reduced modulo the buffer size. The problem with that is that it makes it impossible to distinguish "buffer full" from "buffer empty", because in both situations one has head==tail. This can easily be demonstrated: Build sandbox with RX_BUFFER enabled, set the RX_BUFFER_SIZE to 32, and try pasting the string 01234567890123456789012345678901 Nothing seems to happen, but in reality, all characters have been read and put into the buffer, but then tstc ends up believing nothing is in the buffer anyway because upriv->rd_ptr == upriv->wr_ptr. A better approach is to let the indices be free-running, and only reduce them modulo the buffer size when accessing the array. Then "empty" is head-tail==0 and "full" is head-tail==size. This does rely on the buffer size being a power-of-two and the free-running indices simply wrapping around to 0 when incremented beyond the maximal positive value. Incidentally, that change from signed to unsigned int also improves code generation quite a bit: In C, (signed int)%(signed int) is defined to have the sign of the dividend (so (-35) % 32 is -3, not 29), and hence despite the modulus being a power-of-two, x % 32 does not actually compile to the same as a simple x & 31 - on x86 with -Os, it seems that gcc ends up emitting an idiv instruction, which is quite expensive. Signed-off-by:
-
Tom Rini authored
Jerome Forissier <jerome.forissier@linaro.org> says: This is a rework of a patch series by Maxim Uvarov: "net/lwip: add lwip library for the network stack" [1]. The goal is to introduce the lwIP TCP/IP stack [2] [3] as an alternative to the current implementation in net/, selectable with Kconfig, and ultimately keep only lwIP if possible. Some reasons for doing so are: - Make the support of HTTPS in the wget command easier. Javier T. and Raymond M. (CC'd) have some additional lwIP and Mbed TLS patches to do so. With that it becomes possible to fetch and launch a distro installer such as Debian etc. using a secure, authenticated connection directly from the U-Boot shell. Several use cases: * Authentication: prevent MITM attack (third party replacing the binary with a different one) * Confidentiality: prevent third parties from grabbing a copy of the image as it is being downloaded * Allow connection to servers that do not support plain HTTP anymore (this is becoming more and more common on the Internet these days) - Possibly benefit from additional features implemented in lwIP - Less code to maintain in U-Boot Prior to applying this series, the lwIP stack needs to be added as a Git subtree with the following command: $ git subtree add --squash --prefix lib/lwip/lwip \ https://github.com/lwip-tcpip/lwip.git STABLE-2_2_0_RELEASE Notes 1. A number of features are currently incompatible with NET_LWIP: DFU_TFTP, FASTBOOT, SPL_NET, ETH_SANDBOX, ETH_SANDBOX_RAW, DM_ETH. They all make assumptions on how the network stack is implemented and/or pull sybols that are not trivially exported from lwIP. Some interface rework may be needed. 2. Due to the above, and in order to provide some level of testing of the lwIP code in CI even when the legacy NET is the default, a new QEMU configuration is introduced (qemu_arm64_lwip_defconfig) which is based on qemu_arm64_defconfig with NET_LWIP and CMD_*_LWIP enabled. In addition to that, this series has some [TESTING] patches which make NET_LWIP the default. [1] https://lore.kernel.org/all/20231127125726.3735-1-maxim.uvarov@linaro.org/ [2] https://www.nongnu.org/lwip/ [3] https://en.wikipedia.org/wiki/LwIP Link: https://lore.kernel.org/r/cover.1729070678.git.jerome.forissier@linaro.org
-
Add myself as a maintainer for the lwIP network stack integration code and network commands as well as the sandbox ethernet driver for lwIP. Signed-off-by:
Jerome Forissier <jerome.forissier@linaro.org> Acked-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org>
-
Build and run qemu_arm64_lwip_defconfig in CI. This tests the lightweight IP (lwIP) implementation of the dhcp, tftpboot and ping commands. Signed-off-by: -
Add support for setting the TFTP block size. The default value (1468) is fine for Ethernet and allows a better throughput than the TFTP default (512), if the server supports the blksize option of course. I tested this change with qemu_arm64_lwip_defconfig. The throughput is now 875 KiB/s vs. 313 KiB/s before. That is still a low number, but I think we can't expect more without implementing the windowsize option. Signed-off-by:
-
The TFTP protocol uses a default block size of 512 bytes. This value is sub-optimal for ethernet devices, which have a MTU (Maximum Transmission Unit) of 1500 bytes. When taking into acount the overhead of the IP and UDP layers, this leaves 1468 bytes for the TFTP payload. This patch introduces a new function: tftp_client_set_blksize() which may be used to change the block size from the default. It has to be called after tftp_client_init() and before tftp_get(). If the server does not support the option, the client will still accept to receive 512-byte blocks. Submitted upstream: https://savannah.nongnu.org/patch/index.php?10462 Signed-off-by:
-
Add qemu_arm64_lwip_defconfig which #include's qemu_arm64_defconfig and selects NET_LWIP instead of NET. This config has all the supported net commands enabled. Signed-off-by:
-
Support "bdinfo -e" when lwIP is selected. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
Add support for the wget command with NET_LWIP. The command normally expects a URL: wget [loadaddr] url, but it also accepts the legacy syntax: wget [loadaddr] [server:]file. The server IP may alternatively be supplied via ${httpserverip} which has higher priority than ${serverip}. Based on code initially developed by Maxim U. Signed-off-by:Maxim Uvarov <muvarov@gmail.com> Cc: Maxim Uvarov <muvarov@gmail.com> Signed-off-by:
-
Extract some code from cmd/net.c that will be useful in a subsequent commit to implement wget with NET_LWIP. Signed-off-by:
-
Add CMD_DNS when NET_LWIP is enabled to provide the dns command using lwIP. Signed-off-by:
-
Add support for the the ping command with NET_LWIP. The implementation is derived from lwIP's contrib/apps/ping/ping.c. Signed-off-by:
-
Implement do_tftpb(). This implementation of the tftp command supports an optional port number. For example: tftp 192.168.0.30:9069:file.bin It also supports taking the server IP from ${tftpserverip} if defined, before falling back to ${serverip}. Signed-off-by: -
The TFTP app should not bind to the TFTP server port when configured as a client. Instead, the local port should be chosen from the dynamic range (49152 ~ 65535) so that if the application is stopped and started again, the remote server will not consider the new packets as part of the same context (which would cause an error since a new RRQ would be unexpected). Submitted upstream: https://savannah.nongnu.org/patch/?10480 Signed-off-by:
-
Add what it takes to enable NETDEVICES with NET_LWIP and enable DHCP as well as the dhcp command. CMD_TFTPBOOT is selected by BOOTMETH_EFI due to this code having an implicit dependency on do_tftpb(). Note that PXE is likely non-fonctional with NET_LWIP (or at least not 100% functional) because DHCP option 209 is not supported by the lwIP library. Therefore, BOOTP_PXE_DHCP_OPTION cannot be enabled. Signed-off-by:
-
Build the lwIP library when NET_LWIP is enabled. The following files are adaptation layers written specially for U-Boot: lib/lwip/u-boot/arch/cc.h lib/lwip/u-boot/arch/sys_arch.h (empty) lib/lwip/u-boot/limits.h (empty) lib/lwip/u-boot/lwipopts.h They were initially contributed by Maxim in a previous RFC patch series. The lwIP stack needs to be added as a Git subtree with the following command: $ git subtree add --squash --prefix lib/lwip/lwip \ https://github.com/lwip-tcpip/lwip.git STABLE-2_2_0_RELEASE Signed-off-by:
-
Add a function to start a given network device, and update eth_init() to use it. Signed-off-by:
-
Make net.h a wrapper which includes net-common.h and either net-legacy.h or net-lwip.h based on NET_LWIP. The function copy_filename() can be useful when NET_LWIP is enabled, therefore move it out of net/net.c which is built only when networking choice is NET and create a new file net/net-common.c. Signed-off-by:
-
Prepare the introduction of the lwIP (lightweight IP) TCP/IP stack by adding a new net/lwip/ directory and the NET_LWIP symbol. Network support is either NO_NET, NET (legacy stack) or NET_LWIP. Subsequent commits will introduce the lwIP code, re-work the NETDEVICE integration and port some of the NET commands and features to lwIP. SPL_NET cannot be enabled when NET_LWIP=y. SPL_NET pulls some symbols that are part of NET (such as arp_init(), arp_timeout_check(), arp_receive(), net_arp_wait_packet_ip()). lwIP support in SPL may be added later. Similarly, DFU_TFTP and FASTBOOT are not compatible with NET_LWIP because of dependencies on net_loop(), tftp_timeout_ms, tftp_timeout_count_max and other NET things. Let's add a dependency on !NET_LWIP for now. SANDBOX can select NET_LWIP but doing so will currently disable the eth dm tests as well as the wget tests which have strong dependencies on the NET code. Other adjustments to Kconfig files are made to fix "unmet direct dependencies detected" for USB_FUNCTION_SDP and CMD_FASTBOOT when the default networking stack is set to NET_LWIP ("default NET_LWIP" instead of "default NET" in Kconfig). The networking stack is now a choice between NO_NET, NET and NET_LWIP. Therefore '# CONFIG_NET is not set' should be 'CONFIG_NO_NET=y'. Adjust the defconfigs accordingly. Signed-off-by: -
When DSA_SANDBOX is not set, the sandbox tests fail as follows: $ ./test/py/test.py --build-dir=$(pwd) -k bootdev_test_any [...] Scanning for bootflows with label '9' [...] Cannot find '9' (err=-19) This is due to the device list containing two less entries than expected. Therefore, look for label '7' when DSA_SANDBOX is disabled. The actual use case is NET_LWIP=y (to be introduced in later patches) which implies DSA_SANDBOX=n for the time being. Signed-off-by: -
When DSA_SANDBOX is not set, the sandbox tests fail as follows: $ ./test/py/test.py --build-dir=$(pwd) -k bootdev_test_any [...] Test: bootdev_test_any: bootdev.c test/boot/bootdev.c:156, bootdev_test_any(): "mmc2" = media->name: Expected "mmc2", got "mmc0" [...] This is due to the device list containing two less entries than expected. Therefore, adjust the expected index to be two less when DSA_SANDBOX is disabled. The actual use case is NET_LWIP=y (to be introduced in later patches) which implies DSA_SANDBOX=n for the time being. Signed-off-by:
-
Introduce ETH_SANDBOX_LWIP which enables a mock driver similar to ETH_SANDOX but without the dependencies on the legacy network stack (NET) so that it may be enabled when the lwIP stack (NET_LWIP) is introduced. The driver does nothing at this stage but its presence will allow dm_test_iommu_noiommu [1] to pass. [1] ./u-boot -T -c "ut dm dm_test_iommu_noiommu" Signed-off-by:
-
The tools-only defconfig causes troubles on MacOSX due to the default C compiler being Clang (LLVM) rather than GCC and more specifically due to [1]. Therefore replace "# CONFIG_FOO is not set" with the equivalent "CONFIG_FOO=n" using the following command: $ sed -i -e 's/# \(CONFIG_[^ ]*\) is not set/\1=n/' \ configs/tools-only_defconfig This fixes the tools_only_macOS CI job on GitHub [2]. [1] https://github.com/llvm/llvm-project/issues/78778 [2] https://dev.azure.com/u-boot/u-boot/_build/results?buildId=9105&view=results Suggested-by: -
Tom Rini authored
-
Tom Rini authored
git-subtree-dir: lib/lwip/lwip git-subtree-split: 0a0452b2c39bdd91e252aef045c115f88f6ca773
-
Tom Rini authored
:hile we had hoped to be able to remove these options finally, it was missed that zynq still requires these currently. This reverts commit 5b9261fb and commit 099b6df5. Reported-by:
-
- Oct 15, 2024
-
-
-
Tom Rini authored
Sughosh Ganu <sughosh.ganu@linaro.org> says: This is part two of the series to have the EFI and LMB modules have a coherent view of memory. Part one of this goal was to change the LMB module to have a global and persistent memory map. Those patches have now been applied to the next branch. These patches are changing the EFI memory allocation API's such that they rely on the LMB module to allocate RAM memory. This fixes the current scenario where the EFI memory module has no visibility of the allocations/reservations made by the LMB module. One thing to note here is that this is limited to the RAM memory region, i.e. the EFI_CONVENTIONAL_MEMORY type. Any other memory type that is to be added to the EFI memory map, still gets handled by the EFI memory module. Changes since V3: * Add comments for the LMB_NOOVERWRITE and LMB_NONOTIFY flags * Drop use of is_addr_in_ram() function * Drop use of CONFIG_MEM_MAP_UPDATE_NOTIFY symbol to check if the notification needs to be sent. * s/lmb_notify/lmb_should_notify * Put a check for EFI_LOADER in the lmb_should_notify() function Some test logs to highlight the issue that is being fixed by the series. Without patch series -------------------- lmb_dump_all: memory.count = 0x1 memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none reserved.count = 0x3 reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map reserved[2] [0x7f77da00-0x820fffff], 0x02982600 bytes flags: no-overwrite => efidebug memmap -- does not show regions allocated by lmb Missing TPMv2 device for EFI_TCG_PROTOCOL Type Start End Attributes ================ ================ ================ ========== CONVENTIONAL 0000000040000000-000000007f751000 WB BOOT DATA 000000007f751000-000000007f756000 WB RUNTIME DATA 000000007f756000-000000007f757000 WB|RT BOOT DATA 000000007f757000-000000007f758000 WB RUNTIME DATA 000000007f758000-000000007f77a000 WB|RT BOOT DATA 000000007f77a000-000000007f781000 WB BOOT CODE 000000007f781000-00000000807b5000 WB RUNTIME DATA 00000000807b5000-00000000807b6000 WB|RT BOOT CODE 00000000807b6000-00000000817c0000 WB RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT BOOT CODE 00000000817d0000-0000000082100000 WB => Trying to allocate EFI memory with already allocated region succeeds(should fail) --------------------------------------------------------------------------------- => efi_mem alloc 2000 42000000 Address returned 0x42000000 => efidebug memmap Type Start End Attributes ================ ================ ================ ========== CONVENTIONAL 0000000040000000-0000000042000000 WB BOOT DATA 0000000042000000-0000000042002000 WB CONVENTIONAL 0000000042002000-000000007f751000 WB BOOT DATA 000000007f751000-000000007f756000 WB RUNTIME DATA 000000007f756000-000000007f757000 WB|RT BOOT DATA 000000007f757000-000000007f758000 WB RUNTIME DATA 000000007f758000-000000007f77a000 WB|RT BOOT DATA 000000007f77a000-000000007f781000 WB BOOT CODE 000000007f781000-00000000807b5000 WB RUNTIME DATA 00000000807b5000-00000000807b6000 WB|RT BOOT CODE 00000000807b6000-00000000817c0000 WB RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT BOOT CODE 00000000817d0000-0000000082100000 WB => With patch series ----------------- lmb_dump_all: memory.count = 0x1 memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none reserved.count = 0x4 reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map reserved[2] [0x7f74f000-0x7f77dfff], 0x0002f000 bytes flags: no-notify, no-overwrite reserved[3] [0x7f77ea00-0x820fffff], 0x02981600 bytes flags: no-overwrite => efidebug memmap Type Start End Attributes ================ ================ ================ ========== BOOT DATA 000000000e100000-000000000f000000 WB CONVENTIONAL 0000000040000000-0000000042000000 WB BOOT DATA 0000000042000000-0000000042200000 WB CONVENTIONAL 0000000042200000-000000007f74e000 WB BOOT DATA 000000007f74e000-000000007f753000 WB RUNTIME DATA 000000007f753000-000000007f754000 WB|RT BOOT DATA 000000007f754000-000000007f755000 WB RUNTIME DATA 000000007f755000-000000007f777000 WB|RT BOOT DATA 000000007f777000-00000000807b6000 WB RUNTIME DATA 00000000807b6000-00000000807b7000 WB|RT BOOT DATA 00000000807b7000-00000000817c0000 WB RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT BOOT DATA 00000000817d0000-0000000082100000 WB Trying to allocate EFI memory with already allocated region fails ----------------------------------------------------------------- => efi_mem alloc 2000 42000000 efi_allocate_pages failed 800000000000000e => Trying to allocate EFI memory with non-allocated region succeeds ---------------------------------------------------------------- => efi_mem alloc 2000 42200000 Address returned 0x42200000 => efidebug memmap Type Start End Attributes ================ ================ ================ ========== BOOT DATA 000000000e100000-000000000f000000 WB CONVENTIONAL 0000000040000000-0000000042000000 WB BOOT DATA 0000000042000000-0000000042202000 WB CONVENTIONAL 0000000042202000-000000007f74d000 WB BOOT DATA 000000007f74d000-000000007f752000 WB RUNTIME DATA 000000007f752000-000000007f753000 WB|RT BOOT DATA 000000007f753000-000000007f754000 WB RUNTIME DATA 000000007f754000-000000007f776000 WB|RT BOOT DATA 000000007f776000-00000000807b5000 WB RUNTIME DATA 00000000807b5000-00000000807b6000 WB|RT BOOT DATA 00000000807b6000-00000000817c0000 WB RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT BOOT DATA 00000000817d0000-0000000082100000 WB => lmb_dump_all: memory.count = 0x1 memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none reserved.count = 0x5 reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map reserved[2] [0x42200000-0x42201fff], 0x00002000 bytes flags: no-notify, no-overwrite reserved[3] [0x7f74e000-0x7f77cfff], 0x0002f000 bytes flags: no-notify, no-overwrite reserved[4] [0x7f77da00-0x820fffff], 0x02982600 bytes flags: no-overwrite Link: https://lore.kernel.org/r/20241015153717.401371-1-sughosh.ganu@linaro.org
-
