The logic in get_details() retrieves the default source directory from
the Labgrid settings. This is convenient for interactive use, since it
allows pytests to be run from any directory and still find the source
tree.

However, it is not actually correct.

Gitlab sets the current directory to the source tree and expects that to
be used. At present it is ignored. The result is that Gitlab builds
whatever happens to be in the default source directory, ignoring the
tree it is supposed to be building.

Fix this by using the directory of the source tree, always. This is
obtained by looking at the grandparent of the conftest.py file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Tom Rini <trini@konsulko.com>
Fixes: bf89a8f1fc2 ("test: Introduce the concept of a role")
Tested-by: Tom Rini <trini@konsulko.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>

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>

Since net_test_wget() is testing a command and is in test/cmd it should
be in the 'cmd' test suite, not 'lib'.

Saving and restoring the values of the environment variables that the
test manipulates is necessary to avoid a regression when running the
whole ut test suite. A minimal reproducer is:

 $ ./u-boot -T -c "ut cmd net_test_wget; ut dm dm_test_eth_act" | \
     grep -E "(Test:|Failures:)"

Reported-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>

Janne Grunau <j@jannau.net> says:

Starting with v2024.10 dev_iommu_dma_unmap calls during device removal
trigger a NULL pointer dereference in the Apple dart iommu driver. The
iommu device is removed before its user. The sparsely used DM_FLAG_VITAL
flag is intended to describe this dependency. Add it to the driver.

Adding this flag is unfortunately not enough since the boot routines
except the arm one simply remove all drivers. Add and use a new function
which calls
    dm_remove_devioce_flags(DM_REMOVE_ACTIVE_ALL | DM_REMOVE_NON_VITAL);
    dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL);
to ensure this order dependency is head consistently.

Link: https://lore.kernel.org/r/20241123-iommu_apple_dart_ordering-v2-0-cc2ade6dde97@jannau.net

This replaces dm_remove_devices_flags() calls in all boot
implementations to ensure non vital devices are consistently removed
first. All boot implementation except arch/arm/lib/bootm.c currently
just call dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL). This can result
in crashes when dependencies between devices exists. The driver model's
design document describes DM_FLAG_VITAL as "indicates that the device is
'vital' to the operation of other devices". Device removal at boot
should follow this.

Instead of adding dm_remove_devices_flags() with (DM_REMOVE_ACTIVE_ALL |
DM_REMOVE_NON_VITAL) everywhere add dm_remove_devices_active() which
does this.

Fixes a NULL pointer deref in the apple dart IOMMU driver during EFI
boot. The xhci-pci (driver which depends on the IOMMU to work) removes
its mapping on removal. This explodes when the IOMMU device was removed
first.

dm_remove_devices_flags() is kept since it is used for testing of
device_remove() calls in dm.

Signed-off-by: Janne Grunau <j@jannau.net>

Provide a unit test for the hextoull() function.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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>

We make fewer calls to dm_test_restore() since
commit fbdac8155c89 ("test: Expand implementation of ut_list_has_dm_tests()")

Because of this some valid test combinations are now broken:

$ ./test/py/test.py --bd sandbox --build -k test_ut
$ ./test/py/test.py --bd sandbox --build -k "bootflow_android or bootflow_cros"

Shows:

  Expected '  2  cros         ready   mmc          4 mmc5.bootdev.part_4       ',
  got '  2  cros         ready   mmc          2 mmc5.bootdev.part_2       '

Here prep_mmc_bootdev() is called twice and it will bind bootmeth_cros twice.

Since bootmeth_cros is bound twice, 'bootflow scan' will find 2x the
expected bootflows.

Before
commit fbdac8155c89 ("test: Expand implementation of ut_list_has_dm_tests()")
this did not happen because a cleanup was called each time.

Add UTF_DM and UTF_SCAN_FDT flags to both tests to make sure that the
bootmeths are unbound after the test finishes.

Fixes: fbdac8155c89 ("test: Expand implementation of ut_list_has_dm_tests()")
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

ut_check_console_line() does include an assert.
Pass the result to ut_assertok().

Addresses-Coverity-ID:  514958 Error handling issues
Fixes: 7dfafcd65ef3 ("test: unit test for hash command")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>