[PATCH v3 1/3] test: gpio: include in build, and fixup bitrot

[Heiko Schocher]

Hello Rasmus,

On 04.11.25 18:44, Rasmus Villemoes wrote:
> 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 at prevas.dk>
> ---
>   test/dm/Makefile |  2 +-
>   test/dm/gpio.c   | 13 ++++++++-----
>   2 files changed, 9 insertions(+), 6 deletions(-)

Thanks!

Reviewed-by: Heiko Schocher <hs at nabladev.com>

bye,
Heiko



-- 
Nabla Software Engineering
HRB 40522 Augsburg
Phone: +49 821 45592596
E-Mail: office at nabladev.com
Geschäftsführer : Stefano Babic