u-boot.git/test/lib, branch v2025.01 Unnamed repository; edit this file 'description' to name the repository. lmb: Return -EEXIST in lmb_add_region_flags() if region already added 2024-12-12T15:20:32+00:00 Sam Protsenko semen.protsenko@linaro.org 2024-12-11T02:17:01+00:00 8b8b35a4f5edc8c3579ff82500b32655f94ec4c8 An attempt to add the already added LMB region using lmb_add_region_flags() ends up in lmb_addrs_overlap() check, which eventually leads to either returning 0 if 'flags' is LMB_NONE, or -1 otherwise. It makes it impossible for the user of this function to catch the case when the region is already added and differentiate it from regular errors. That in turn may lead to incorrect error handling in the caller code, like reporting misleading errors or interrupting the normal code path where it could be treated as the normal case. An example is boot_fdt_reserve_region() function, which might be called twice (e.g. during board startup in initr_lmb(), and then during 'booti' command booting the OS), thus trying to reserve exactly the same memory regions described in the device tree twice, which produces an error message on second call. Return -EEXIST error code in case when the added region exists and it's not LMB_NONE; for LMB_NONE return 0, to conform to unit tests (specifically test_alloc_addr() in test/lib/lmb.c) and the preferred behavior described in commit 1d9aa4a283da ("lmb: Fix the allocation of overlapping memory areas with !LMB_NONE"). The change of lmb_add_region_flags() return values is described in the table below: Return case Pre-1d9 1d9 New ----------------------------------------------------------- Added successfully 0 0 0 Failed to add -1 -1 -1 Already added, flags == LMB_NONE 0 0 0 Already added, flags != LMB_NONE 0 -1 -EEXIST Rework all affected functions and their documentation. Also fix the corresponding unit test which checks reserving the same region with the same flags to account for the changed return value. No functional change is intended (by this patch itself). Fixes: 1d9aa4a283da ("lmb: Fix the allocation of overlapping memory areas with !LMB_NONE") Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com> 
An attempt to add the already added LMB region using
lmb_add_region_flags() ends up in lmb_addrs_overlap() check, which
eventually leads to either returning 0 if 'flags' is LMB_NONE, or -1
otherwise. It makes it impossible for the user of this function to catch
the case when the region is already added and differentiate it from
regular errors. That in turn may lead to incorrect error handling in the
caller code, like reporting misleading errors or interrupting the normal
code path where it could be treated as the normal case. An example is
boot_fdt_reserve_region() function, which might be called twice (e.g.
during board startup in initr_lmb(), and then during 'booti' command
booting the OS), thus trying to reserve exactly the same memory regions
described in the device tree twice, which produces an error message on
second call.

Return -EEXIST error code in case when the added region exists and it's
not LMB_NONE; for LMB_NONE return 0, to conform to unit tests
(specifically test_alloc_addr() in test/lib/lmb.c) and the preferred
behavior described in commit 1d9aa4a283da ("lmb: Fix the allocation of
overlapping memory areas with !LMB_NONE"). The change of
lmb_add_region_flags() return values is described in the table below:

    Return case                        Pre-1d9   1d9    New
    -----------------------------------------------------------
    Added successfully                    0      0      0
    Failed to add                         -1     -1     -1
    Already added, flags == LMB_NONE      0      0      0
    Already added, flags != LMB_NONE      0      -1     -EEXIST

Rework all affected functions and their documentation. Also fix the
corresponding unit test which checks reserving the same region with the
same flags to account for the changed return value.

No functional change is intended (by this patch itself).

Fixes: 1d9aa4a283da ("lmb: Fix the allocation of overlapping memory areas with !LMB_NONE")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Michal Simek <michal.simek@amd.com>
lmb: Fix the allocation of overlapping memory areas with !LMB_NONE 2024-12-05T07:01:44+00:00 Ilias Apalodimas ilias.apalodimas@linaro.org 2024-12-02T14:42:45+00:00 1d9aa4a283daa1e609130b5457c9857d62f1d1cb At the moment the LMB allocator will return 'success' immediately on two consecutive allocations if the second one is smaller and the flags match without resizing the reserved area. This is problematic for two reasons, first of all the new updated allocation won't update the size and we end up holding more memory than needed, but most importantly it breaks the EFI SCT tests since EFI now allocates via LMB. More specifically when EFI requests a specific address twice with the EFI_ALLOCATE_ADDRESS flag set, the first allocation will succeed and update the EFI memory map. Due to the LMB behavior the second allocation will also succeed but the address ranges are already in the EFI memory map due the first allocation. EFI will then fail to update the memory map, returning EFI_OUT_OF_RESOURCES instead of EFI_NOT_FOUND which break EFI conformance. So let's remove the fast check with is problematic anyway and leave LMB resize and calculate address properly. LMB will now - try to resize the reservations for LMB_NONE - return -1 if the memory is not LMB_NONE and already reserved The LMB code needs some cleanup in that part, but since we are close to 2025.01 do the easy fix and plan to refactor it later. Also update the dm tests with the new behavior. Fixes: commit 22f2c9ed9f53 ("efi: memory: use the lmb API's for allocating and freeing memory") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> 
At the moment the LMB allocator will return 'success' immediately on two
consecutive allocations if the second one is smaller and the flags match
without resizing the reserved area.

This is problematic for two reasons, first of all the new updated
allocation won't update the size and we end up holding more memory than
needed, but most importantly it breaks the EFI SCT tests since EFI
now allocates via LMB.

More specifically when EFI requests a specific address twice with the
EFI_ALLOCATE_ADDRESS flag set, the first allocation will succeed and
update the EFI memory map. Due to the LMB behavior the second allocation
will also succeed but the address ranges are already in the EFI memory
map due the first allocation. EFI will then fail to update the memory map,
returning EFI_OUT_OF_RESOURCES instead of EFI_NOT_FOUND which break EFI
conformance.

So let's remove the fast check with is problematic anyway and leave LMB
resize and calculate address properly. LMB will now
- try to resize the reservations for LMB_NONE
- return -1 if the memory is not LMB_NONE and already reserved

The LMB code needs some cleanup in that part, but since we are close to
2025.01 do the easy fix and plan to refactor it later.
Also update the dm tests with the new behavior.

Fixes: commit 22f2c9ed9f53 ("efi: memory: use the lmb API's for allocating and freeing memory")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
test: unit test for hextoull() 2024-11-22T21:04:54+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2024-11-13T21:15:12+00:00 544418999882487c25cc9529d0698f75d824bec0 Provide a unit test for the hextoull() function. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
Provide a unit test for the hextoull() function.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Revert "test: Update time tests to use unit-test asserts" 2024-11-22T20:37:21+00:00 Tom Rini trini@konsulko.com 2024-11-19T14:05:26+00:00 c16fcbc14a7aca15ea6dd5d283506c08920486e0 While at the base level, this conversion looks equivalent, we now see both of these tests failing (due to exceeding their allowed margin for being too slow) in Azure with a very high frequency. This reverts commit 88db4fc5fec20429881896740df61d402b4b1f66. Signed-off-by: Tom Rini <trini@konsulko.com> Tested-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> 
While at the base level, this conversion looks equivalent, we now see
both of these tests failing (due to exceeding their allowed margin for
being too slow) in Azure with a very high frequency.

This reverts commit 88db4fc5fec20429881896740df61d402b4b1f66.

Signed-off-by: Tom Rini <trini@konsulko.com>
Tested-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Merge patch series "test: Tidy up the test/ directory" 2024-11-13T22:02:58+00:00 Tom Rini trini@konsulko.com 2024-11-13T17:59:07+00:00 aa482995a81aff8d9f063e777862f126771f9189 Simon Glass <sjg@chromium.org> says: Some tests do not use the unit-test framework. Others are in a suite of their own, for no obvious reason. This series tidies this up. Link: https://lore.kernel.org/r/20241102193715.432529-1-sjg@chromium.org 
Simon Glass <sjg@chromium.org> says:

Some tests do not use the unit-test framework. Others are in a suite of
their own, for no obvious reason.

This series tidies this up.

Link: https://lore.kernel.org/r/20241102193715.432529-1-sjg@chromium.org
test: Update time tests to use unit-test asserts 2024-11-13T17:56:02+00:00 Simon Glass sjg@chromium.org 2024-11-02T19:37:03+00:00 88db4fc5fec20429881896740df61d402b4b1f66 Rather than returning various error codes, use assertions to check that the test passes. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Tom Rini <trini@konsulko.com> # rpi_3, rpi_4, rpi_arm64, am64x_evm_a53, am64-sk 
Rather than returning various error codes, use assertions to check that
the test passes.

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Tom Rini <trini@konsulko.com> # rpi_3, rpi_4, rpi_arm64, am64x_evm_a53, am64-sk
test: Move time tests into the lib suite 2024-11-13T17:56:02+00:00 Simon Glass sjg@chromium.org 2024-11-02T19:37:02+00:00 dd0057dacb2e8bced192ca7c8698b1704b247908 There is no particular need for the time tests to have their own test command. Move them into the lib suite instead. Update the test functions to match the normal unit-test signature. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Tom Rini <trini@konsulko.com> # rpi_3, rpi_4, rpi_arm64, am64x_evm_a53, am64-sk 
There is no particular need for the time tests to have their own test
command. Move them into the lib suite instead.

Update the test functions to match the normal unit-test signature.

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Tom Rini <trini@konsulko.com> # rpi_3, rpi_4, rpi_arm64, am64x_evm_a53, am64-sk
test: Move time_ut test into lib 2024-11-13T17:56:02+00:00 Simon Glass sjg@chromium.org 2024-11-02T19:37:01+00:00 890d91ff3584fcdcf9dc5ff0b516dcd3a5e55108 This test doesn't belong at the top level. Move it into the lib/ directory, to match its implementation. Rename it to drop the unnecessary _ut suffix. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Tom Rini <trini@konsulko.com> # rpi_3, rpi_4, rpi_arm64, am64x_evm_a53, am64-sk 
This test doesn't belong at the top level. Move it into the lib/
directory, to match its implementation. Rename it to drop the
unnecessary _ut suffix.

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Tom Rini <trini@konsulko.com> # rpi_3, rpi_4, rpi_arm64, am64x_evm_a53, am64-sk
test: Move unicode tests into the lib suite 2024-11-13T17:56:02+00:00 Simon Glass sjg@chromium.org 2024-11-02T19:37:00+00:00 5912a9ea1ad25c9278148950f8653a3c1a03043b There is no particular need for the unicode tests to have their own test suite. Move them into the lib suite instead. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Tom Rini <trini@konsulko.com> # rpi_3, rpi_4, rpi_arm64, am64x_evm_a53, am64-sk 
There is no particular need for the unicode tests to have their own test
suite. Move them into the lib suite instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Tom Rini <trini@konsulko.com> # rpi_3, rpi_4, rpi_arm64, am64x_evm_a53, am64-sk
test: Move unicode_ut test into lib 2024-11-13T17:56:02+00:00 Simon Glass sjg@chromium.org 2024-11-02T19:36:59+00:00 7a27d4187a30ccd77b6bed49af63b8eb792fe9e4 This test doesn't belong at the top level. Move it into the lib/ directory, to match its implementation. Rename it to drop the unnecessary _ut suffix. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Tom Rini <trini@konsulko.com> # rpi_3, rpi_4, rpi_arm64, am64x_evm_a53, am64-sk 
This test doesn't belong at the top level. Move it into the lib/
directory, to match its implementation. Rename it to drop the
unnecessary _ut suffix.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Tom Rini <trini@konsulko.com> # rpi_3, rpi_4, rpi_arm64, am64x_evm_a53, am64-sk