The GitHub dependabot tool has reported a "medium" priority bug
CVE-2025-68146, with this package. Update to the patched version.

Reported-by: GitHub dependabot
Signed-off-by: Tom Rini <trini@konsulko.com>

The current FDT decoding tests calculate the memory required
for FDT manipulation by directly adding a fixed margin to
fdt_totalsize(gd->fdt_blob). The static analyzer flagged
"gd->fdt_blob->totalsize" as a tainted value being passed
to fdt_open_into().

Ensure the size is validated by checking that the total size
is within a reasonable maximum FDT limit for unit tests.

Signed-off-by: Adriana Nicolae <adriana@arista.com>

When I modified this code I meant to accept the LGPL offer to convert the
license to GPL. However, while there is an LGPL 2.1, the next version of
the GPL after 2.0 is 3.0. Fix the license version

Fixess: c4ac52f55d9 ("test: Add test for strlcat")
Signed-off-by: Sean Anderson <seanga2@gmail.com>

The Linux kernel can discover SMBIOS tables through two primary methods:
1. Via EFI tables, when using EFI boot;
2. Via the 'smbios3-entrypoint' property in the /chosen node of the
device tree.

When U-Boot boots a Linux kernel using a non-EFI command ("bootm",
"bootz", or "booti"), the kernel relies on the device tree to detect
the hardware. If SMBIOS tables are available in U-Boot, they should
be passed to the kernel via this device tree property.

This patch modifies boot_fdt_prepare(), to inject the SMBIOSv3 table
address into the device tree if there is a table generated by U-boot.
The "board_fdt_chosen_smbios" is weak in order to leave the possibilty
for specific boards to select custom SMBIOS addresses.

The changes in this patch are added in the context of supporting this
device tree property in linux kernel:
https://lkml.org/lkml/2025/10/24/1393

Device tree schema was updated to include the "smbios3-entrypoint" node
in pull request: https://github.com/devicetree-org/dt-schema/pull/177

Signed-off-by: Adriana Nicolae <adriana@arista.com>

The location of memory depends on the board. Do not assume memory at fixed
memory locations. Use memalign() instead to allocate a buffer.

Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

The location of memory depends on the board. Do not assume memory at fixed
memory locations. Use calloc() instead to allocate buffers.

Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

On x86 commit 9b35dbc93fd4 ("x86: Show the timestamp counter with bdinfo")
has added another bdinfo output line.

On RISC-V commit 66b5ee9c558e ("riscv: add RISC-V fields to bdinfo
command") implemented arch_print_bdinfo().

Update the bdinfo test accordingly.

Fixes: 9b35dbc93fd4 ("x86: Show the timestamp counter with bdinfo")
Fixes: 66b5ee9c558e ("riscv: add RISC-V fields to bdinfo command")
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

The location and size of flash is device-dependent. Do not make any
assumption about the location and size.

Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

In fdt_test_chosen() currently we test if DM_RNG is configured.
CONFIG_DM_RNG=y does not imply that a RNG device actually exists.
For instance QEMU may be called with -device virtio-rng-device or not.
The current test framework evicts the virtio RNG device even if QEMU is
called with -device virtio-rng-device.

In the fdt_test_chosen() check if a RNG device exists.
Ignore 'No RNG device' messages.

Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

The `fdt apply` sub-command is only available if CONFIG_OF_LIBFDT_OVERLAY
is enabled.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>