Add a test suite exercising the whole lifetime and callbacks
of interconnect with a fake 5 providers with a split node graph.

The test suite checks the calculus are right and goes to the correct
nodes, and the lifetime of the node is correct.

Link: https://patch.msgid.link/20251120-topic-interconnect-next-v5-2-e8a82720da5d@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>

Commit ebaa3d053e5 ("test: fix CONFIG_ACPIGEN dependencies"), which
got into v2022.10-rc1, accidentally left out a $
before (CONFIG_DM_GPIO), with the effect that test/dm/gpio.c has not
been built for three years.

Unsurprisingly, the code in there has bit-rotted.

- There's a missing ; causing plain build fail.

  That code was added in 9bf87e256c2 ("test: dm: update test for
  open-drain/open-source emulation in gpio-uclass"), which was part of
  v2020.07-rc3, i.e. long before the commit causing gpio.c to not be
  built at all. It did build at that time, but also, the missing
  semicolon wasn't found when fa847bb409d ("test: Wrap assert macros
  in ({ ... }) and fix missing semicolons") happened in 2023.

- Commit 592b6f394ae ("led: add function naming option from linux")
  bumped sandbox,gpio-count for bank gpio_a in test.dts to 25, but
  didn't update the expected global gpio numbers accordingly.

- The "lookup by label" test likely worked when it was added, but then I
  inadvertently broke it when I noticed that dm_gpio_lookup_label()
  seemed to be broken in commit 10e66449d7e ("gpio-uclass: fix gpio
  lookup by label") - which landed in v2023.01-rc1, so after gpio.c
  was no longer being built.

  The "label" (which is a u-boot concept) that a "hogged gpio" gets is
  <gpio hog node name>.gpio-hog, which is why it used to work with the
  strncmp() but doesn't with strcmp().

  We can either revert 10e66449d7e or append the ".gpio-hog" suffix as
  done below. I don't really have a dog in that race; when I did
  10e66449d7e, it was because I thought the "lookup by label" was
  actually about the standardized gpio-line-names property, but then I
  learnt it was not, so is not at all useful to me.

- The leak check now fails.

  Test: gpio_leak: gpio.c
  test/dm/core.c:112, dm_leak_check_end(): uts->start.uordblks == end.uordblks: Expected 0x2a95b0 (2790832), got 0x2a9650 (2790992)
  test/dm/gpio.c:328, dm_test_gpio_leak(): 0 == dm_leak_check_end(uts): Expected 0x0 (0), got 0x1 (1)
  Test: gpio_leak: gpio.c (flat tree)
  test/dm/core.c:112, dm_leak_check_end(): uts->start.uordblks == end.uordblks: Expected 0x2a9650 (2790992), got 0x2a9700 (2791168)
  test/dm/gpio.c:328, dm_test_gpio_leak(): 0 == dm_leak_check_end(uts): Expected 0x0 (0), got 0x1 (1)

  And it fails with the same differences (160/176) even if I
  remove the three lines that actually exercise any of the gpio code,
  i.e. make the whole function amount to

    ut_assertok(dm_leak_check_end(uts));

  Test: gpio_leak: gpio.c
  test/dm/core.c:112, dm_leak_check_end(): uts->start.uordblks == end.uordblks: Expected 0x2a95b0 (2790832), got 0x2a9650 (2790992)
  test/dm/gpio.c:325, dm_test_gpio_leak(): 0 == dm_leak_check_end(uts): Expected 0x0 (0), got 0x1 (1)
  Test: gpio_leak: gpio.c (flat tree)
  test/dm/core.c:112, dm_leak_check_end(): uts->start.uordblks == end.uordblks: Expected 0x2a9650 (2790992), got 0x2a9700 (2791168)
  test/dm/gpio.c:325, dm_test_gpio_leak(): 0 == dm_leak_check_end(uts): Expected 0x0 (0), got 0x1 (1)

  So I suspect that the leak is somewhere in the test framework
  setup/teardown code - dm_leack_check_end() isn't really used
  anywhere else except in a dm/core test. Bisecting to figure out
  where that was introduced is somewhat of a hassle because of the
  other bitrot, and because of the SWIG failure that makes it very
  hard to build older U-Boots.

  So since it's better to have most of the gpio tests actually
  working instead of leaving all of gpio.c as dead code, #if 0 that
  part out and leave it as an archeological exercise.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Heiko Schocher <hs@nabladev.com>

The video test here is specific to the sandbox SDL video driver, so only
build it when that is enabled rather than VIDEO is enabled.

Reported-by: Alison Chaiken <alison@she-devel.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

Add s simple test for the I3C uclass in sandbox.

Signed-off-by: Dinesh Maniyam <dinesh.maniyam@altera.com>

Create a basic test suit for AES DM uclass that covers all available
operations.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>

Convert the tests to use the do_ping() interface which is now
common to NET and NET_LWIP. This allows running most network test with
SANDBOX and NET_LWIP. A few things to note though:

1. The ARP and IPv6 tests are enabled for NET only

2. The net_retry test is modified to use eth0 (eth@10002000) as the
active (but disabled) interface, and therefore we expect eth1
(eth@10003000) to be the fallback when "netretry" is "yes". This is in
replacement of eth7 (lan1) and eth0 (eth@10002000) respectively.
Indeed, it seems eth7 works with NET by chance and it certainly does not
work with NET_LWIP. I observed that even with NET,
sandbox_eth_disable_response(1, true) has no effect: remove it and
the test still passes. The interface ID is not correct to begin with; 1
corresponds to eth1 (eth@10003000) as shown by debug traces, it is not
eth7 (lan1). And using index 7 causes a SEGV.  In fact, it is not the
call to sandbox_eth_disable_response() that prevents the stack from
processing the ICMP reply but the timeout caused by the call to
sandbox_eth_skip_timeout(). Here is what happens when trying to ping
using the eth7 (lan1) interface with NET:

 do_ping(...)
     net_loop(PING)
         ping_start()
         eth_rx()
             sb_eth_recv()
                 time_test_add_offset(11000UL);
         if (get_timer(0) - time_start > time_delta)
             ping_timeout_handler()  // ping error, as expected

And the same with NET_LWIP:

 do_ping(...)
     ping_loop(...)
         sys_check_timeouts()
         net_lwip_rx(...)
             sb_eth_recv()
                 time_test_add_offset(11000UL);
             netif->input(...)  // the packet is processed succesfully

By choosing eth0 and sandbox_eth_disable_response(0, true), the incoming
packet is indeed discarded and things work as expected with both network
stacks.

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

Add tests for video bridge ops.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Use the new suite-runner to run these tests instead.

Signed-off-by: Simon Glass <sjg@chromium.org>

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: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Use PHASE_ as the symbol to select a particular XPL build. This means
that SPL_TPL_ is no-longer set.

Update the comment in bootstage to refer to this symbol, instead of
SPL_

Signed-off-by: Simon Glass <sjg@chromium.org>